The present invention relates generally to pipelining of start, stop, address byte and data byte transfer instructions in I2C logic systems.
Conventional I2C systems are described in detail in the publication “THE I2C-BUS SPECIFICATION, VERSION 2.1, JANUARY 2000”, which is incorporated herein by reference. I2C devices ordinarily have a CPU (although some “stand-alone” I2C devices, such as an ADC, may not include a CPU). I2C devices are usually implemented at a certain protocol level that may be dependent on their main intended use. An I2C device functioning in its slave mode is often referred to simply as a “slave”, and an I2 device functioning in its master mode is often referred to simply as a “master”.
The closest prior art is believed to be the assignee's MSC 1211 product, relevant parts of which are shown in prior art FIGS. 1-4. It may be helpful to provide a description of the basic structure and operation of the prior art before proceeding to a description of the present invention. Referring to prior art FIG. 1, I2C system 1 includes a serial data bus conductor 2 which conducts the serial clock data signal SDA and a serial clock conductor 3 that conducts the serial clock signal SCK. I2C system 1 also includes an I2C slave device 5 and an I2C master device 10, both of which are connected to SCK conductor 3 and SDA conductor 2. The serial data bus conductor 2 and serial clock conductor 3 are collectively referred to as the “I2C bus”.
Slave device 5 includes an N-channel transistor 17 having its drain connected to SCK conductor 3 and its source connected to a ground conductor. The gate of transistor 17 is connected to control logic circuit 24, which includes a finite state machine (FSM). Slave device 5 includes a transmit/receive shift register 22 connected to SDA conductor 2. Transmit/receive shift register 22 is bidirectionally coupled by multiple conductors to a read/write buffer 23, which is coupled by multiple conductors to control logic circuit 24. Control logic circuit 24 can produce an interrupt signal INT on conductor 27, which is connected to an interrupt input of slave CPU 11. Control logic circuit 24 also is bidirectionally coupled via multiple control conductors 26 to slave CPU 11.
Master device 10 includes clock generation circuitry 6, shown in detail in FIG. 3. Clock generation circuitry 6 is coupled to SCK conductor 3. Clock generation circuitry 6 is bidirectionally coupled by multiple conductors 53 to a control logic circuit 240, which includes a conventional finite state machine. Control logic circuit 240 produces an interrupt signal INT on conductor 52, which is connected to an interrupt input of a master CPU 110. Master CPU 110 receives control signals on multiple conductors 51 from control logic 240 and sends control signals on multiple conductors 50 to control logic circuit 240. Master device 10 also includes a transmit/receive shift register 220 which is bidirectionally coupled to SDA conductor 2. Transmit/receive shift register 220 is also bidirectionally coupled by multiple conductors to a read/write buffer 230, which is bidirectionally coupled by multiple conductors to control logic circuit 240.
By way of definition, the term “I2C hardware” is used herein to refer to all of the circuitry of an I2C device except its CPU. For example, in FIG. 1, I2C device 5 acts as a slave and includes a CPU 10 and “I2C hardware” including transmit/receive shift register 22, read/write buffer 23, and control logic 24. I2C device 10 acts as a master and includes a CPU 110 and I2C hardware including clock generation circuitry 6, transmit/receive shift register 220, read/write buffer 230, and control logic 240.
Also by way of definition, it is to be understood that each time the CPU of an I2C device “executes” an instruction of a user program, the CPU “sends” one or more control signals or “commands” to the I2C hardware of that I2C device, and the I2C hardware acts in response to such control signals or commands. Whenever the I2C hardware performs a function that results in a signal or signal “condition” being transmitted on the I2C bus 2,3, the signal or signal condition is said to be “sent to” or “sent on” the I2C bus. That is, an instruction of a user program is accessed and immediately “executed” by the CPU which then “sends” a corresponding control signal or command to the I2C hardware, which responds by “sending” a corresponding signal or “condition” on the I2C bus 2,3. Usually, the I2C hardware provides feedback to the CPU (either by directly interrupting the CPU or by being polled by the CPU, both of which are very time-consuming) to let the CPU know the status of the I2C hardware so it can operate to control the I2C hardware and/or execute the next instruction.
It should be understood that the amount of time required for the I2C hardware to respond to the commands bears no relation to the amount of time required for the CPU to execute the instruction, because the time required for the CPU to execute the instruction depends on the rate at which the CPU is clocked but the time required for the I2C hardware to respond to the command could be much shorter or much longer than the amount of time required for the I2C hardware to respond to the commands.
FIG. 2 illustrates a typical sequence of events during operation of a conventional I2C system including a master and a slave to help in understanding basic I2C system operation. Both a master and a slave can function in a receive mode or a send mode. In every data time frame there are nine clock pulses, the first eight clock pulses of which are used by the master to send the data byte. During the ninth clock pulse a “0” is produced on SDA conductor 2 by the slave if an acknowledge signal ACK is to be sent by the slave, or alternatively, a “1” is produced on the SDA conductor by the slave if a “not acknowledge” signal or condition NACK (hereinafter referred to as a “not acknowledge signal NACK”) is to be sent by the slave to inform the master that the slave is not acknowledging that it received the data byte and is not accepting or reading the data byte being transmitted on SDA conductor 2. (An example of the process of the slave reading a data byte includes the slave CPU 11 in FIG. 1 performing the step of reading R/W buffer 23.) If no slave is trying to pull SDA conductor 2 low (i.e., a NACK signal is being sent), SDA conductor 2 assumes a high value, i.e., a “1” level, and if SDA conductor 2 is low during the ninth clock pulse of the present data time frame, that means the slave is notifying the master that it has received the data byte sent by the master on SDA conductor 2.
The user software determines in advance whether the slave is to send either an acknowledge signal ACK or a “not acknowledge” signal NACK on the SDA conductor during the ninth clock pulse of the present data time frame.
In FIG. 2, block 60 indicates whether the user program has determined whether or not the slave will respond by sending either a previously set up acknowledge signal ACK or “not acknowledge” signal NACK. After the data byte has been received by the slave, it will then “send” whichever of the ACK signal or NACK signal was previously set up in accordance with block 60. As indicated in block 30-1 of FIG. 2, the slave in a conventional I2C system receives a data byte transmitted by the master during the first eight SCK pulses of a 9-pulse data time-frame. Referring to block 31-1, the slave sends either an acknowledge signal ACK on SDA conductor 2 to let the master know that the slave has received the transmit data byte or a “not acknowledge” signal NACK to let the master know that the slave is not accepting or reading any data byte being sent by the master on SDA conductor 2.
Referring to block 32-1A in FIG. 2, after receiving the data byte and sending an acknowledge signal ACK, the I2C slave hardware does not know what its CPU will do next. For example, the slave may not yet have a next byte available to be sent to the master. What the slave can then do is to stretch clock SCK to indicate that the master must wait, and then the slave can interrupt the slave CPU and inform it that the slave has received the current byte and has sent an acknowledge signal ACK. To determine if the slave has received the data byte and to determine whether the slave can send an acknowledge signal, slave CPU 11 can either service an interrupt or perform a polling operation. If control logic 24 sends an interrupt signal INT to slave CPU 11, it reads the data byte that it has received, as indicated in block 32-1B. Once the data byte is read, slave CPU 11, at the beginning of block 32-1C, also sets up the slave as indicated in block 61 of FIG. 2 to send an acknowledge signal ACK or a “not acknowledge” signal or condition NACK after it receives the next data byte. Then, as indicated in block 32-1C, the slave “releases the stretch” of SCK.
Note that after the slave has received the first data byte, it does not always need to set up the acknowledge/“not acknowledge” decision again for each of the multiple successive data bytes to be received by the slave. For example, if the slave CPU wants the slave to receive 10 successive data bytes, the slave does not need to set up the acknowledge/“not acknowledge” decision again for each of the remaining 9 data bytes. The ACK/NACK bit (i.e., the ninth bit of each data time frame) remains set until it is cleared. The slave therefore will send an acknowledge signal ACK for each of the 10 data bytes without the acknowledge/“not acknowledge” bit being reset. After the stretch release referred to in block 32-1C of FIG. 2, the master then can send the next data byte on SDA conductor 2, and the process in the slave is repeated for the next data byte, as indicated in blocks 30-2 and 31-2.
As general background, it should be understood that the above described process is a “handshaking” process wherein the slave stretches clock signal SCK to inform the master to not send any more SCK pulses, and the slave control logic then sends an interrupt signal INT to its own slave CPU 11 and informs slave CPU 11 that a data byte has been received and the clock SCK has been stretched. Then the slave CPU 11 reads that data byte and sets up the appropriate conditions for the next event to happen (e.g., the slave CPU sets up the slave to send either an ACK signal or a NACK signal after the next data byte is received as indicated in block 61, after the present stretch of SCK has been released,). Then, when the slave is ready it “releases the stretch” of SCK. The master then can continue control of clock signal SCK and data signal SDA.
A “back-to-back stop and start operation” in a conventional I2C system such as the above mentioned MSC 1211 includes executing a stop instruction followed, after a particular delay, by executing a separate start instruction. When master 10 is communicating to slave 5, at the end of that communication master 10 sends a stop condition on I2C bus 2,3 before attempting to initiate communication with another slave by means of another start instruction. Master 10 executes a “combined” stop and start instruction wherein a stop instruction and a start instruction are pipelined. First, the pipelined stop instruction is executed. The control logic/finite state machine 87 does not have to notify master CPU 110 that the stop condition has been sent to I2C bus 2,3 as is required in earlier I2C systems. Instead, control logic/finite state machine 87 automatically sends the start condition on I2C 2,3 after a predetermined delay. Then a start condition is automatically sent on I2C bus 2,3, in response to the pipelined start instruction. This avoids the separate programming and executing of stop and start instructions required by earlier I2C systems.
The logic circuitry of a prior art I2C system such as the MSC 1211 cannot simultaneously handle the combination of a start instruction, a stop instruction, and an address byte instruction and/or a data transfer instruction. The CPU must be notified by the I2C hardware that execution of the start instruction is complete before the CPU can execute the address byte transfer instruction. Also, the software executed by a CPU of an I2C device has to wait until the stop, start and address byte instructions have been executed and acted on by the I2C hardware before the data byte transfer instruction is executed and before the required signals are sent by the CPU to the I2C hardware. This requirement reduces the I2C bus speed and the data throughput rate of the I2C system.
The circuitry shown in FIG. 4 is included in the assignee's above mentioned MSC 1211 product for allowing master 10 to “pipeline” a stop instruction and a start instruction so the programmer can provide a stop instruction and the following start instruction at the same point of an application program to be executed by master 10 and thereby avoid the inconvenience of providing and executing the start instruction at a later point in the application program.
Referring to FIG. 4, master 10 includes a master CPU 110. A transmit buffer (Tx buffer) 76 is bidirectionally coupled by conductors 78 to master CPU 110. Transmit buffer 76 is coupled to a transmit shift register (Tx shift reg.) 77. Transmit shift register 77 is coupled by a conductor 80 to a “control finite state machine 87”, hereinafter referred to simply as “finite state machine 87”.
Control logic 94 feeds back signals to finite state machine 87 via a bus 95 to enable it to make logical decisions according to the present circumstances. Data can be serially coupled from finite state machine 87 to conventional pad interface circuitry 79 by means of conductor 83. Clock generation circuit 6 of prior art FIG. 3 is included in control logic 94. Master CPU 110 is bidirectionally coupled by conductors 82 to start instruction circuitry 81, which is also bidirectionally coupled by conductors 84 to finite state machine 87. Master CPU 110 also is bidirectionally coupled by conductors 91 to stop instruction circuitry 85. Stop instruction circuitry 85 is bidirectionally coupled by conductors 88 to finite state machine 87.
A receive buffer circuit (Rx buffer) 89 is bidirectionally coupled by conductors 89 to master CPU 110, and also is coupled to a receive shift register (Rx shift register) 90. Receive shift register 90 is coupled by conductor 93 to finite state machine 87. Conductor 92 conducts serial data from pad interface circuitry 79 to finite state machine 87. Pad interface circuitry 79 is bidirectionally coupled to SDA conductor 2 and SCK conductor 3. Master CPU 110 is bidirectionally coupled by conductors 96 to control logic 94. Control logic 94 is bidirectionally coupled by various conductors 95 to finite state machine 87 and pad interface circuitry 79.
SDA conductor 2 and SCK conductor 3 are connected to corresponding integrated circuit bonding pads (not shown). Control signals coupled to the pad interface circuitry 79 for each of the SCK and SDA bidirectional bonding pads, respectively, including internal enable signals on conductors 95 applied to control pad interface circuitry 79, which allow the bidirectional SDA conductor and the bidirectional SCK conductor to function both as serial input inputs and serial outputs of master 10.
Above-mentioned stop instruction circuit 85 includes a stop instruction bit, which, when set by master CPU 110, causes a stop condition to be generated on I2C bus 2,3 at the appropriate time by master 10. Similarly, start instruction circuit 81 includes a start instruction bit, which, when set by master CPU 110, causes the following start condition to be generated later on I2C bus 2,3, after the appropriate delay time has been counted by tick counter 40. Master CPU 110 can set the start bit in block 81 while it is sending or receiving a data byte. Once the start bit is set, master CPU 110 waits to be informed that the current byte transaction to be finished, and then executes the start instruction.
In response to a combined stop/start instruction, master CPU 110 can, according to I2C protocol, write into start instruction circuitry 81 and stop instruction circuitry 85, and also into transmit buffer 76 and receive buffer 89. A stop instruction must be executed first, and the execution of a start instruction must follow the execution of a stop instruction by a predetermined delay. Execution of the start instruction must be followed by other communication, i.e., transmission of an address byte and one or more data bytes.
The logic circuitry in block 75 determines if master CPU 110 is writing “parallel” instructions such as a combined stop/start instruction, wherein finite state machine 87 checks the parallel instructions in accordance with the present situation and accordingly sends appropriate timing information to master CPU 110 at times allowed by the I2C protocol. Finite state machine 87 can send signals, such as interrupt signals, to control logic 94, from which master CPU 110 can obtain appropriate information regarding when to later cause an address byte to be transmitted on SDA conductor 2.
Specifically, a stop condition is generated first, followed by a counting of the time required before execution of the next start condition can begin. The start condition then is sent on I2C bus 2,3. The counting referred to is based on the microsecond tick counter circuit 40 in FIG. 3, which is included in finite state machine 87. Tick counter 40 is loaded with the required amount of time to be counted from either block 35 or block 36 in FIG. 3, corresponding either to standard mode or fast mode I2C operation. The loaded times are then counted down by tick counter circuit 40 to determine the time intervals between the times at which instructions are set up and the times at which they are to be executed. After the required time interval is counted, the I2C hardware sends the start condition on I2C bus 2,3.
A known I2C protocol determines whether a byte is an address byte or a data byte, and finite state machine 87 always determines that an address byte is the first byte to be transmitted after a start condition has been sent on I2C bus 2,3, but has no other way of distinguishing between an address byte and the data byte.
In the receive mode, if receive buffer 89 is empty after a data byte has been received by master 10 and loaded into receive shift register 90, the data byte is transferred to receive buffer 89, and master 10 can continue to receive a next data byte during to the next eight CLK pulses.
To understand how the transmit and receive shift registers operate, assume that master 10 wants to transmit a byte on SDA conductor 2. To accomplish this, master CPU 110 writes the byte to transmit buffer 76. Transmit buffer 76 checks to see if transmit shift register 77 is presently empty, and if it is empty, transmit buffer 76 sends the byte to transmit shift register 77. Transmit shift register 77 then signals finite state machine 87 to determine whether master 10 is in the correct mode to send a byte. If master 10 currently is in its receive mode, it is receiving data from a slave, in which case finite state machine 87 does not allow master 10 to receive data on SDA conductor 2. Finite state machine 87 waits for the data byte being received to be available to master CPU 110. When this has occurred, receive shift register 90 signals finite state machine 87, causing it to resume generation of SCK to allow master 10 to transmit the byte on SDA conductor 2.
As explained above, the prior art MSC 1211 has to wait until master CPU 110 has been interrupted and notified that the start condition has been sent on I2C bus 2,3 and before CPU 110 can write the address byte into the transmit buffer 76. It is important to note that the MSC 1211 only combines a stop instruction and start instruction as a single instruction. However, the MSC 1211 can not combine or pipeline the start instruction and address byte together. The I2C hardware must inform master CPU 110, either by means of an interrupt operation or a polling operation, that the start condition has been sent on I2C bus 2,3 before beginning execution of an address byte instruction. Similarly, the I2C hardware must inform master CPU 110, either by means of an interrupt operation or a polling operation, that the sending of the address byte on the I2C bus is complete and that an acknowledge (ACK) or not acknowledge (NACK) message has been received from a receiving I2C slave device before beginning execution of a data byte transfer instruction.
It would be desirable to avoid the interrupt or polling operation and the delay required in prior art devices (such as the MSC 1211) prior to sending an address byte on the I2C bus. It also would be desirable to avoid the interrupt operation or polling operation and the delay required in prior art devices (such as the MSC 1211) prior to sending a data byte on the I2C bus.
Thus, there is an unmet need for a circuit and method for avoiding the interrupt or polling operation and the delay required in the prior art I2C systems immediately before sending an address byte on the I2C bus.
There also is an unmet need for a circuit and method for avoiding the interrupt operation or polling operation and the delay required in the prior art I2C systems immediately before sending a data byte on the I2C bus.
There also is an unmet need for reducing the number of interrupts required in the prior art I2C systems immediately before sending data bytes on the I2C bus.